In database storage platforms, including previously released versions of Microsoft's SQL Server, small value objects are copied without much concern for the overhead involved because such overhead costs are relatively nominal. However, for large-value objects, the overhead costs are much more significant and can negatively impact overall performance.
Heretofore large objects have been stored using large object (LOB) data types—text, ntext, and image data types—to overcome the size limitations of varchar, nvarchar, and varbinary types for values too large for these data types that are best suited to small data objects. However, there have been many restrictions on what has been allowed in the programming model with large objects, and the infrastructure led to an error prone implementation of large objects. For example, most string functions and operators are not allowed for LOBs, and there are also shortcomings with the text pointer functions in particular regard to insertions and deletions. (Text pointers are physical references used as row locators in earlier releases of SQL Server). Moreover, there is no efficient means for modifying one or more rows of a LOB at a time, and there is no support for LOB variables or copy functions for LOBs of any kind. These limitations, and others, result in LOBs being perceptibly different from other data types and therefore more difficult to use.
What is needed is a large object infrastructure where users/programmers can handle large values (data blocks) in the same way smaller values are handled, and thereby eliminate the user-perceptible differences in the handling of small and large values, in order to provide a single comprehensive programming model.